IP Multimedia services provide a dynamic combination of voice, video, messaging, data, etc. within the same session. By growing the number of basic applications and the media which it is possible to combine, the number of services offered to the end subscribers will grow, and the inter-personal communication experience will be enriched. This will lead to a new generation of personalized, rich multimedia communication services, including so-called “combinational IP Multimedia” services.
IP Multimedia Subsystem (IMS) is the technology defined by the Third Generation Partnership Project (3GPP) and ETSI TISPAN group to provide IP Multimedia services over mobile communication networks (3GPP TS 22.228, TS 23.228, TS 24.229, TS 29.228, TS 29.229, TS 29.328 and TS 29.329 Releases 5 to 7, and TS 24.173 Release 7). IMS provides key features to enrich the end-subscriber person-to-person communication experience through the use of standardised IMS Service Enablers, which facilitate new rich person-to-person (client-to-client) communication services as well as person-to-content (client-to-server) services over IP-based networks. The IMS makes use of the Session Initiation Protocol (SIP) to set up and control calls or sessions between subscriber terminals (or subscriber terminals and application servers). The Session Description Protocol (SDP), carried by SIP signalling, is used to describe and negotiate the media components of the session. Whilst SIP was created as a subscriber-to-subscriber protocol, IMS allows operators and service providers to control subscriber access to services and to charge subscribers accordingly.
By way of example, FIG. 1 illustrates schematically how the IMS fits into the mobile network architecture in the case of a GPRS/PS access network (IMS can of course operate over other access networks). Call/Session Control Functions (CSCFs) operate as SIP proxies within the IMS. The 3GPP architecture defines three types of CSCFs: the Proxy CSCF (P-CSCF) which is the first point of contact within the IMS for a SIP terminal; the Serving CSCF (S-CSCF) which provides services to the subscriber and which the subscriber is subscribed to; and the Interrogating CSCF (I-CSCF) whose role is to identify the correct S-CSCF and to forward to that S-CSCF a request received from a SIP terminal via a P-CSCF.
Within the IMS service network, Application Servers (ASs) are provided for implementing IMS service functionality. Application Servers provide services to end users in an IMS system, and may be connected either as end-points over the 3GPP defined Mr interface, or “linked in” by an S-CSCF over the 3GPP defined ISC interface. In the latter case, Initial Filter Criteria (IFC) are used by an S-CSCF to determine which Applications Servers should be “linked in” during a SIP Session establishment (or indeed for the purpose of any SIP method, session or non-session related). The IFCs are received by the S-CSCF from a Home Subscriber Server (HSS) during the IMS registration procedure as part of a subscriber's Subscriber Profile.
Whilst early IMS implementations relied upon the static allocation of ASs to subscribers, i.e. with the ASs identities being specified in the IFCs for that client, more recently it has been recognised that this is undesirable both to ensure load sharing across ASs and to provide a measure of fault tolerance, i.e. backup in the event that an AS fails. Consider for example the Multimedia telephony (MMTeI) IMS service. This can be deployed (across a given IMS network) on many ASs, and as such ASs can be dynamically allocated to users. A user's application data is fetched from the HSS transparent data at user IMS registration and cached in the dynamically allocated AS. At user deregistration the AS discards the user's cached application data.
There are a number of possible mechanisms for dynamic AS allocation. One example involves the S-CSCF resolving, at registration, a generic service AS identity received from the HSS into a specific AS identity, e.g. using a DNS lookup type operation. Another example involves some sort of AS pool front-end that receives a registration request from the S-CSCF at user registration, the front-end selecting one AS from the pool and forwarding the request to that AS. This front-end may subsequently route SIP traffic to the allocated AS based upon an association between the user identity and AS instance.
It has been widely recognised that it is desirable to provide an interface between telecommunications networks and third party provider applications, e.g. via a web graphical user interface (e.g. the W3C defined Web Services), in order to allow telecom functionality and services to be available over the web. For example, it might be desirable to allow a user to initiate a call to a company by clicking on a link on the company's web page (“click-to-dial”). In the case of the IMS, the 3GPP defined interface known as Parlay X can be used to interface an AS to a third party service provider application. This interface provides functionality to manage, i.e. start and stop, “subscriptions” belonging to the service provider application. A subscription is defined by                1 or many IMS users (PUI) to which the subscription relates;        1 or many call events (e.g. new call, busy);        a notification address of the service provider application; and        a subscription identity (used for example when the subscription is stopped).        
When an AS has started a subscription, and handles a call that matches the criteria (PUI+call event) specified in the subscription, it uses the notification address to send a trigger to the service provider application. A service provider may start subscriptions within the IMS network on a per user basis. However, it is more likely that a subscription will be started for a set of users, e.g. one subscription identifying all users subscribing to a particular service.
A third party service provider application will typically be pre-configured with an IP address and port number of an IMS AS with which it is to communicate (e.g. via the Parlay X interface). Alternatively, the service provider application may be preconfigured with a URL of the AS, with the service provider application resolving the URL into an IP address and port number using a DNS look-up or the like.
In view of the likely dynamic allocation of ASs (in respect of a given service, e.g. MMTeI) to users, a service provider application cannot have a priori knowledge of the ASs to which users associated with a given subscription will be allocated. Moreover, different subscribers may be allocated to different ASs belonging to a service pool. As such, a subscription must be distributed to all relevant ASs in the IMS network which can be allocated to a user. Furthermore, when the subscription is stopped, it must be removed from all ASs. FIG. 2 illustrates schematically the subscription process where a particular IMS service is facilitated by a pool of ASs, namely AS1, AS2 and AS3. Users X, Y and Z are allocated to the three ASs respectively. A third party application wishing to start a subscription in the IMS in respect of three users X, Y and V, must start it in all three ASs as X and Y are allocated to different ASs, and as an AS has not yet been allocated to user V.
One approach to starting the subscription in all ASs associated with a particular service is for the third party service provider application to start the subscription directly in each AS. The service provider application could obtain the addresses of the requisite ASs by performing a DNS look-up on a generic AS URL. This is however undesirable due both to the load placed on the service provider application, and to the inability of such a mechanism to respond to dynamic changes in the AS, for example upon initialisation of a new AS for a particular IMS service.